Blockwise extraction of document metadata

ABSTRACT

Methods, computer program products, and systems are presented. The methods include, for instance: obtaining a document image, wherein the document image includes a plurality of objects; identifying a plurality of macroblocks within the document image; performing microblock processing within macroblocks of the plurality of macroblocks, wherein the microblock processing includes examining content of microblocks within a macroblock for extraction of key-value pairs, the examining content including performing an ontological analysis of microblocks, wherein the microblock processing includes associating confidence levels to the extracted key-value pairs; and outputting metadata based on the performing microblock processing within macroblocks of the plurality of macroblocks.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.15/828,813, filed Dec. 1, 2017, entitled “Blockwise Extraction ofDocument Metadata”, which is incorporated by reference herein in itsentirety.

TECHNICAL FIELD

The present disclosure relates to document processing technology, andmore particularly to methods, computer program products, and systems forcognitively digitizing data from document images.

BACKGROUND

In conventional document processing, ink-on-paper documents are scannedpage by page as respective visual images in preparation. A resultingdocument file of scanned papers is typically a series of visual image ofpages. Each visual image of a page does not have accessible content, andexisting document processing applications may digitize certain visualimage patterns into digitized data, which may be accessible andoperational by use of corresponding computer program application. Suchdata digitizing process of visual images are often referred to asextraction, or data extraction. In light of the amount of informationrepresented in legacy paper forms and scanned documents images,extraction of such document images may greatly affect generalproductivity in many areas of industry as well as society.

SUMMARY

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of amethod. The method includes, for example: obtaining a document image,wherein the document image includes a plurality of objects; identifyinga plurality of macroblocks within the document image; performingmicroblock processing within macroblocks of the plurality ofmacroblocks, wherein the microblock processing includes examiningcontent of microblocks within a macroblock for extraction of key-valuepairs, the examining content including performing an ontologicalanalysis of microblocks, wherein the microblock processing includesassociating confidence levels to the extracted key-value pairs; andoutputting metadata based on the performing microblock processing withinmacroblocks of the plurality of macroblocks.

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of acomputer program product including a computer readable storage mediumreadable by one or more processor circuit and storing instructions forexecution by one or more processor for performing a method including,for example: obtaining a document image, wherein the document imageincludes a plurality of objects; identifying a plurality of macroblockswithin the document image; performing microblock processing withinmacroblocks of the plurality of macroblocks, wherein the microblockprocessing includes examining content of microblocks within a macroblockfor extraction of key-value pairs, the examining content includingperforming an ontological analysis of microblocks, wherein themicroblock processing includes associating confidence levels to theextracted key-value pairs; and outputting metadata based on theperforming microblock processing within macroblocks of the plurality ofmacroblocks.

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of asystem including: a memory; one or more processor in communication withmemory; and program instructions executable by the one or more processorvia the memory to perform a method including, for example: obtaining adocument image, wherein the document image includes a plurality ofobjects; identifying a plurality of macroblocks within the documentimage; performing microblock processing within macroblocks of theplurality of macroblocks, wherein the microblock processing includesexamining content of microblocks within a macroblock for extraction ofkey-value pairs, the examining content including performing anontological analysis of microblocks, wherein the microblock processingincludes associating confidence levels to the extracted key-value pairs;and outputting metadata based on the performing microblock processingwithin macroblocks of the plurality of macroblocks.

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of amethod. The method includes, for example: obtaining a document image,wherein the document image includes a plurality of objects; identifyinga macroblock within the document image, wherein the macroblock includesobjects of the plurality of objects; examining content of microblockswithin an area of the macroblock of the document image for extraction ofone or more key-value pair, wherein the examining includes examiningcontent of unaligned microblocks within the area of the microblock, andwherein the examining content of unaligned microblocks within the areaof the microblock includes applying an ontological analysis; associatinga confidence level to a key-value pair of the one or more key-valuepair; and outputting the one or more key-value pair

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of acomputer program product including a computer readable storage mediumreadable by one or more processor circuit and storing instructions forexecution by one or more processor for performing a method including,for example: obtaining a document image, wherein the document imageincludes a plurality of objects; identifying a macroblock within thedocument image, wherein the macroblock includes objects of the pluralityof objects; examining content of microblocks within an area of themacroblock of the document image for extraction of one or more key-valuepair, wherein the examining includes examining content of unalignedmicroblocks within the area of the microblock, and wherein the examiningcontent of unaligned microblocks within the area of the microblockincludes applying an ontological analysis; associating a confidencelevel to a key-value pair of the one or more key-value pair; andoutputting the one or more key-value pair.

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of asystem including: a memory; one or more processor in communication withmemory; and program instructions executable by the one or more processorvia the memory to perform a method including, for example: obtaining adocument image, wherein the document image includes a plurality ofobjects; identifying a macroblock within the document image, wherein themacroblock includes objects of the plurality of objects; examiningcontent of microblocks within an area of the macroblock of the documentimage for extraction of one or more key-value pair, wherein theexamining includes examining content of unaligned microblocks within thearea of the microblock, and wherein the examining content of unalignedmicroblocks within the area of the microblock includes applying anontological analysis; associating a confidence level to a key-value pairof the one or more key-value pair; and outputting the one or morekey-value pair

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of amethod. The method includes, for example: obtaining a document image,wherein the document image includes a plurality of objects; processingthe document image to identify a baseline styling parameter value, thebaseline styling parameter value specifying a baseline font height;identifying for each word of a line of text of the document image arelative styling parameter, the relative styling parameter being definedin reference to the baseline styling parameter value, wherein therelative styling parameter specifies a font height of a word of text ofthe text line as a percentage value of the baseline styling parametervalue; and providing the relative styling parameter as output metadatafor output.

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of acomputer program product including a computer readable storage mediumreadable by one or more processor circuit and storing instructions forexecution by one or more processor for performing a method forextracting data from a document image including, for example: obtaininga document image, wherein the document image includes a plurality ofobjects; processing the document image to identify a baseline stylingparameter value, the baseline styling parameter value specifying abaseline font height; identifying for each word of a line of text of thedocument image a relative styling parameter, the relative stylingparameter being defined in reference to the baseline styling parametervalue, wherein the relative styling parameter specifies a font height ofa word of text of the text line as a percentage of a value of thebaseline styling parameter value; and providing the relative stylingparameter as output metadata for output.

The shortcomings of the prior art are overcome, and additionaladvantages are provided, through the provision, in one aspect, of asystem including: a memory; one or more processor in communication withmemory; and program instructions executable by the one or more processorvia the memory to perform a method including for example: obtaining adocument image, wherein the document image includes a plurality ofobjects; processing the document image to identify a baseline stylingparameter value, the baseline styling parameter value specifying abaseline font height; identifying for each word of a line of text of thedocument image a relative styling parameter, the relative stylingparameter being defined in reference to the baseline styling parametervalue, wherein the relative styling parameter specifies a font height ofa word of text of the text line as a percentage of the baseline stylingparameter value; and providing the relative styling parameter as outputmetadata for output.

Additional features are realized through the techniques set forthherein. Other embodiments and aspects, including but not limited tocomputer program product and system, are described in detail herein andare considered a part of the claimed invention.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more aspects of the present invention are particularly pointedout and distinctly claimed as examples in the claims at the conclusionof the specification. The foregoing and other objects, features, andadvantages of the invention are apparent from the following detaileddescription taken in conjunction with the accompanying drawings inwhich:

FIG. 1 depicts a system for cognitively digitizing document images, inaccordance with one or more embodiments set forth herein;

FIG. 2 depicts a flowchart of operations performed by the cognitivedocument digitization engine, in accordance with one or more embodimentsset forth herein;

FIG. 3 depicts detailed operations of multi-layered blockidentification, as performed by the cognitive document digitizationengine, in accordance with one or more embodiments set forth herein;

FIG. 4 depicts exemplary document images, to which adjustable blockidentification parameters are applied in order to identify macroblocks,in accordance with one or more embodiments set forth herein;

FIG. 5 depicts detailed operations of macroblock processing whereinmacroblocks are identified and subject to processing for identificationof microblocks therein;

FIG. 6 depicts an exemplary document image, to which adjustable blockidentification parameters are applied in order to identify macroblocks,in accordance with one or more embodiments set forth herein;

FIG. 7 depicts an exemplary document image, to which adjustable blockidentification parameters are applied in order to identify macroblocks,in accordance with one or more embodiments set forth herein;

FIG. 8 depicts an exemplary document image, to which adjustable blockidentification parameters are applied in order to identify macroblocks,in accordance with one or more embodiments set forth herein;

FIG. 9 depicts output metadata output by a document digitization enginein accordance with one or more embodiments set forth herein;

FIG. 10 depicts output metadata output by a document digitization enginein accordance with one or more embodiments set forth herein;

FIG. 11 depicts a cloud computing node according to an embodiment of thepresent invention;

FIG. 12 depicts a cloud computing environment according to an embodimentof the present invention; and

FIG. 13 depicts abstraction model layers according to an embodiment ofthe present invention.

DETAILED DESCRIPTION

FIG. 1 depicts a system 100 for cognitively digitizing document images,in accordance with one or more embodiments set forth herein.

Extracting computational data from document image is often unsuccessfuldue to wide variety of custom formats, individual styles, diversealignments, and non-text contents. Consequently, enormous amount ofinformation represented in documents images are not as accessible asfully digitized documents. Document images without digitization havelimited usages such as visual viewing and archival purposes. In thealternative, the time and cost required for manual digitization of suchdocument images would be prohibitive, considering the number ofdocuments that would be benefited from digitization.

Digital documents are often preferred for the convenience incomputationally using data represented in the documents. Whenpen-on-paper documents are scanned in, the documents are a series ofvisual image of pages, but not computationally ready for usage asdigital data. Accordingly, many document digitization applications havebeen developed in order to accurately extract computational data fromdocument images. In existing document processing applications, numerouscustom formats and organizations of documents present challenges inprocessing visual images of a document and extracting computational dataout of the document. Embodiments herein implement a cognitivedigitization process of document images as human readers understandmeanings conveyed by visual marks in documents, and improves efficiencyand accuracy of data extraction from document images. Embodiments hereinextract metadata from documents by methods that are not reliant solelyon alignment of objects or on semantical relationships between objectsbut rather which employ a combination of alignment based processing andsemantics based processing.

The system 100 includes a document digitization engine 120. The documentdigitization engine 120 receives a document image 181 from a user 101via a user device 110. The document image 181 is a visual image of adocument created for a certain information, which is not computationaldata. For example, a scanned image of a paper document does not have anydigitized data so text in the scanned image may not be searched or beread into another application as data input. The document image 181 hasnumerous objects, which may be extracted as computational data. In thisspecification, the term “object” refers to an identifiable individualentity in the document image, and the term “microblock” refers to asmallest unit of candidate data identified from a corresponding objectin the document, for various analyses in order to find relationshipsamong the objects, according to a microblock machine logic delineationrule. The document digitization engine 120 represents each microblockwith numerous microblock characteristics, including content, position,style of each microblock.

The document digitization engine 120 automatically extracts data fromthe document image 181 based on multi-layered collinearity analysis suchthat the information extracted from images of texts and numbers in thedocument image 181 may be computational data that is usable by otherprograms and applications. A relational database 150 coupled to thedocument digitization engine 120 stores a key-value pair (KVP) 155 of aplurality of KVPs corresponding to the data extracted from the documentimage 181. The document digitization engine 120 associates the key-valuepairs with respective confidence levels. The term “key-value pair”refers to a primary data representation unit with a key and a value, inwhich the key describes or identifies the value. The KVPs may behierarchically organized into a larger data structure, as often seen inrelational database tables.

The document digitization engine 120 may determine metadata 140 forobjects in the document image 181. Metadata 140 which defines digitizedcomputational data may include, for example, characteristics metadata145 such as content, position, and style, key-value-pairs metadata 146which may include associated confidence levels, and relative stylingmetadata 148 which specifies styling at an area of a document inrelation to a larger area. The output metadata may be organized tospecify a taxonomy indicating hierarchical relationships between objectsof a document image 181. The document digitization engine 120 may outputmetadata in a suitable markup e.g. JSON or XML, and in one embodimentmay output metadata in a machine readable stylesheet representative ofcontent of the document. Document digitization engine 120 may outputmetadata to one or more process interface 149. The document digitizationengine 120 may use one or more external tool 170 such as OpticalCharacter Recognition (OCR) for determining metadata.

In this specification, the term “collinearity” refers to a geometricalalignment among recognizable objects in the document image 181 as thedocument digitization engine 120 deems meaningful in order to identify amacroblock based on two or more microblocks as being collinear; term“microblock” refers to individual objects recognized from the documentimage 181; and term “macroblock” refers to a group of two or moremicroblocks to form a meaningful data unit such as a Key-Value Pair(KVP) and a column, or a row, in a table. A macroblock may define aspatial area that encompasses a spatial area of two or more microblocks.

With conventional document image processing, discovering collinearitycorrectly in documents of countless custom formats for extracting usabledata is an ongoing process. The document digitization engine 120utilizes a multi-layered approach with collinearity and semantics, inorder to achieve a more comprehensive recognition of the document image181 than conventional document image processing applications, and inorder to extract usable data from the document image 181 as a result.

The document digitization engine 120 analyzes collinearity amongst themicroblocks based on a plurality of adjustable collinearity parameters,in order to extract computational data from a plurality of microblocksdetermined to be aligned in the document image 181. Examples of cohesivedata may include individual key-value pairs and sets of KVPs as in atable in a document. Examples of the adjustable collinearity parametersmay include, but are not limited to, font height and style changes,alignments, and punctuations. A key-value pair is a macroblock thatincludes two microblocks, as the key is a microblock and the value isanother microblock, where the two microblocks align with one anotherbased on the collinearity analysis by the document digitization engine120.

The document digitization engine 120 further utilizes various semanticinformation stored in a semantic database 130 in order to extract datafrom the document image 181. A few examples of the information in thesemantic database 130 may include, but are not limited to, one or moredocument class 131, one or more key alias 135, and key ontology data137. Detailed operations of the document digitization engine 120 isdescribed in FIGS. 2, 3, and 4.

In the semantic database 130, each of the one or more document class 131corresponds to one or more class keys 133, that any document in eachdocument class is to include. For example, when a document is of apurchase invoice class, a corresponding class key may include, but arenot limited to, a name, a transaction date, an item list, an amount,etc.

In the semantic database 130, the one or more key alias 135 includesaliases for numerous keys, which may appear in the document image 181 inplace of a key. The one or more key alias 135 is often looked up for theone or more class keys 133, because all the class keys corresponding toa class are to appear in one document. For example, the class key mayspecify an “Account Number” class key, but the document image 181 mayhave a key with “Acct. #” text, but not a text of “Account Number”. Theone or more key alias 135 lists interchangeable names, such as “AccountNumber” and “Acct. #” in order to accommodate analysis and dataextraction of wide variety of customized documents.

Key ontology data 137 of the semantic database 130 defines a set ofconstraints and meanings modeling a domain of knowledge represented bythe document image 181. The key ontology data 137 includes a pluralityof keys that may present in the document image 181. A key 138 among theplurality of keys is associated with various characteristics includingproperties of the key 138, one or more sets to which the key 138belongs, and relationships among members of a same set of the one ormore sets. Also, the document digitization engine 120 may conclude thattwo semantically associated text blocks are collinear. For example, thekey 138 may have a data type 139 property specifying a proper data typeof a value for the key 138, such as a text string for a CustomerLastNamekey, an eight-digit number for a DateOfBirth key. In the same example,if a text string has a common name value such as “Johnson”, the documentdigitization engine 120 may determine the CustomerLastName key and thetext string “Johnson” as a KVP, even though the text string ismisaligned with the key within a proximity range. In the same example,the document digitization engine 120 runs a classifier (one of theexternal tools 170) with the text string “Johnson” in order to determinethat the text string “Johnson” is a data type for names. For anotherexample, the key 138 may be one of the one or more class keys 133, andhave relationships with other class keys defined in the key ontologydata 137, such as an Invoice document class includes both aCustomerNumber class key and an Amount class key.

FIG. 2 depicts a flowchart of operations performed by the documentdigitization engine 120 of FIG. 1, in accordance with one or moreembodiments set forth herein.

In block 210, the document digitization engine 120 receives a documentimage and processes the document image. The received document image mayhave more than one distinctive visual pattern in one page. The documentdigitization engine 120 identifies such patterns as respective sectionsin the document. In this specification, the term “object” refers to animage object in the document image, and the term “microblock” refers toan indivisible unit block identified from a corresponding image object,according to a microblock machine logic delineation rule, forcollinearity analysis. Then the document digitization engine 120proceeds with block 220.

In block 220, the document digitization engine 120 applies a macroblockclassifier to respective sections of the document image 181 using amacroblock classifier such as a table classifier, a word densityclassifier (an area where text density is above a threshold may beidentified as a macroblock), an address classifier, a paragraphclassifier. If the document digitization engine 120 does not discover amacroblock of objects in the document, then the document digitizationengine 120 proceeds with block 230. If the document digitization engine120 discovers one or more macroblock of objects in the document, thenthe document digitization engine 120 proceeds with block 240.

In block 230, the document digitization engine 120 analyzes microblocksin the document image 181 and identifies macroblocks based on extendedcollinearity analysis of the microblocks. Detailed operations of block230 are described in FIG. 3 and corresponding description. Then thedocument digitization engine 120 proceeds with block 250.

In block 240, the document digitization engine 120 respectively analyzesmacroblocks that are identified as a result of macroblock classificationin block 220 or collinearity analysis in block 230. Detailed operationsof block 240 are described in FIG. 5 and corresponding description. Thenthe document digitization engine 120 proceeds with block 250.

In block 250, the document digitization engine 120 returns a result ofdigitized document image having computational data to a user. Thedocument digitization engine 120 optionally receives a feedback 199 onthe result from the user. The document digitization engine 120 updateskey-value pairs generated from block 230 and/or tables generated fromblock 240 according to the feedback, then terminate processing thedocument image 181 received in block 210. In block 250 documentdigitization engine 120 may output metadata e.g. to a process interface149.

The document digitization engine 120 may perform block 230 as well asblock 240, depending on the sections in the document image 181, in orderto support various formats of custom documents having a mixture ofobject clusters and tables of various organizations. The documentdigitization engine 120 may iterate block 230 and/or block 240 asnecessary according to the objects present in the document image 181.

FIG. 3 depicts detailed operations of block 230 of FIG. 2, multi-layeredblock identification, as performed by the document digitization engine120 of FIG. 1, in accordance with one or more embodiments set forthherein.

In block 310, the document digitization engine 120 identifiesmicroblocks in the received document, from corresponding objects. Theobjects may be either a text string, a numerical number, a symbol, or apictorial image. The document digitization engine 120 measureshorizontal and vertical spaces between objects, in absolute distancesand/or in relative proximities, in preparation of collinearity analysis.Then the document digitization engine 120 proceeds with block 320.

In block 320, the document digitization engine 120 identifies amacroblock corresponding to each microblock identified in block 310 byanalyzing the respective positions of two or more microblocks inproximity based on adjustable collinearity parameters of the microblock.The document digitization engine 120 may identify a macroblock based ontwo or more microblocks that are collinear according to the adjustablecollinearity parameters. The document digitization engine 120 proceedswith block 330 upon identifying respective macroblocks for allmicroblocks in the received document.

In one embodiment, the document digitization engine 120 may determinethat two or more microblocks are collinear based on the adjustablecollinearity parameters without exact alignment when the two or moremicroblocks are within a certain distance range, in absolute distancesor in relative positions. The adjustable collinearity parametersinclude: font; paragraph alignment; punctuation mark; and ontologicalmatching. The adjustable collinearity parameter indicates that thedocument digitization engine 120 may associate two microblocks in acollinear relationship even though the two microblocks have distinctivefonts and different sizes/styles, have different paragraph alignments inrespective microblocks, and/or are separated by a punctuation marks.Further, the document digitization engine 120 may determine the twomicroblocks as a macroblock based on key ontology data, in which acertain key name and a data type for the key name is specified, forexample. Examples and detailed description of the adjustablecollinearity parameters are presented in FIG. 4 and correspondingdescription.

In block 330, the document digitization engine 120 determines a class ofthe received document and whether or not all class keys required in theclass of the document have been identified. If the document digitizationengine 120 determines that any class key has not been identified, thenthe document digitization engine 120 proceeds with block 340. If thedocument digitization engine 120 determines that all class keys havebeen identified, then the document digitization engine 120 proceeds withblock 350.

In block 340, the document digitization engine 120 examines allmicroblocks identified in block 310 for respective aliases correspondingto each missing class key. For each alias found in place of a missingclass key, the document digitization engine 120 identifies a macroblockincluding the microblock having the alias, as in block 320. Then thedocument digitization engine 120 proceeds with block 350.

In block 350, the document digitization engine 120 identifies allKey-Value Pairs (KVPs) from the macroblocks identified in block 320 andblock 340. A microblock of each macroblock may correspond to a key in aKVP, and another microblock of the same macroblock may correspond to avalue in the same KVP. The document digitization engine 120 assigns aconfidence level to each identified KVP. The document digitizationengine 120 heuristically determines the confidence level of a KVP basedon various factors such as the level of proximity, ontological matchingof respective key names and data types. For keys and values frequentlyappearing in formal and transactional documents, the confidence levelsof KVPs may be higher than custom keys and values in informal andpersonal documents. Then the document digitization engine 120 proceedswith block 250 of FIG. 2.

FIG. 4 depicts exemplary document images, to which adjustable blockidentification parameters are applied in order to identify macroblocks,in accordance with one or more embodiments set forth herein.

A document 400 includes two microblocks in various configurations. Afirst microblock has a text string “Name”, and a second microblock has atext string “Kevin”. “Name” text in the first microblock may beextracted as a key and “Kevin” text in the second microblock may beextracted as a value of the Name key, from which the documentdigitization engine 120 identifies a macroblock, or a Key-Value pair(KVP), Name=“Kevin”.

Configuration 410 depicts different font sizes in two adjacentmicroblocks, where “Name” microblock has a font smaller than the font of“Kevin” microblock. With existing document processing applications, fontdifferences including size changes would prevent the two microblocksfrom being identified as a macroblock (KVP), which would otherwise forma KVP. The document digitization engine 120 is enabled to identify twomicroblocks having different font sizes as one macroblock (KVP), byusing an adjustable collinearity parameter on font sizes.

Configuration 415 depicts different text styles in two verticallyadjacent microblocks, where “Name” microblock is boldfaced but “Kevin”microblock has a normal face in the next line. With existing documentprocessing applications, text style differences including typefacechanges, for example, when a normal text is boldfaced, italicized, andunderlined, would prevent the two microblocks from being identified as amacroblock (KVP), which would otherwise form a KVP. The documentdigitization engine 120 is enabled to identify two microblocks havingdifferent text styles as one macroblock (KVP), by using an adjustablecollinearity parameter on text styles.

Configuration 420 depicts different paragraph alignments in two adjacentmicroblocks, where “Name” microblock is left aligned but “Kevin”microblock is aligned on the right end. With existing documentprocessing applications, paragraph alignment differences as shown abovewould prevent the two microblocks from being identified as a macroblock(KVP), which would otherwise form a KVP. The document digitizationengine 120 is enabled to identify two microblocks having differentparagraph alignments as one macroblock (KVP), by using an adjustablecollinearity parameter on paragraph alignments.

Configuration 425 depicts different paragraph alignments in twovertically adjacent microblocks, where “Name” microblock is left alignedbut “Kevin” microblock is aligned on the right end in the next line.With existing document processing applications, paragraph alignmentdifferences as shown above would prevent the two microblocks inrespective lines from being identified as a macroblock (KVP), whichwould otherwise form a KVP. The document digitization engine 120 isenabled to identify two microblocks in respective lines having differentparagraph alignments as one macroblock (KVP), by using an adjustablecollinearity parameter on paragraph alignments.

Configuration 430 depicts two adjacent microblocks being separated by apunctuation mark, where “:”, a colon is placed between “Name” microblockand “Kevin” microblock. With existing document processing applications,a separating punctuation mark as shown above may prevent the twomicroblocks from being identified as a macroblock (KVP), which wouldotherwise form a KVP. The document digitization engine 120 is enabled toidentify two microblocks separated by a punctuation mark as onemacroblock (KVP), by using an adjustable collinearity parameter onpunctuation mark separation.

Configuration 435 depicts two vertically adjacent microblocks beingseparated by a punctuation mark, where “:”, a colon is placed between“Name” microblock and “Kevin” microblock in the next line. With existingdocument processing applications, a separating punctuation mark as shownabove may prevent the two microblocks in respective lines from beingidentified as a macroblock (KVP), which would otherwise form a KVP. Thedocument digitization engine 120 is enabled to identify two microblocksin respective lines separated by a punctuation mark as one macroblock(KVP), by using an adjustable collinearity parameter on punctuation markseparation.

Configuration 440 depicts two adjacent microblocks being separated by awide space, where the wide space between “Name” microlock and “Kevin”microblock ordinarily prevents the two microblocks from being identifiedas a macroblock (KVP) with existing document processing applications.The document digitization engine 120 is enabled to identify twomicroblocks separated by such wide space as one macroblock (KVP), bysemantically analyzing texts of the two microblocks and by matching keysand values based on key ontology data, as “Kevin” is of a proper datatype for a value for “Name” key.

Configuration 445 depicts two vertically adjacent microblocks beingseparated by a wide space, where the wide space between “Name”microblock and “Kevin” microblock in the next line ordinarily preventsthe two microblocks from being identified as a macroblock (KVP) inexisting document processing applications. The document digitizationengine 120 is enabled to identify two microblocks in respective linesseparated by such wide space as one macroblock (KVP), by semanticallyanalyzing texts of the two microblocks and by matching keys and valuesbased on key ontology data, as “Kevin” is of a proper data type for avalue for “Name” key.

In certain embodiments, the document digitization engine 120 may have apredefined set of spacing categories, which may include, for example,tight spacing, single spacing (normal spacing), one-and-a-half spacing,double-spacing, and wide spacing, where each spacing category indicate adistinctive likelihood of collinearity between two macroblocks separatedby the respective spacing categories. The set of spacing categories maybe distinctive for microblocks within each macroblock.

The document digitization engine 120 may further apply semanticinterpolation based on the presence of semantic indications such asconjunctions, disjunctions, and related symbols marks indicatingsemantic relations. For example, both “and” and “or” expresscontinuation in a line, as in symbols “&”, “+”. Symbols such as “−” and“*” are often used as a line heading marker in a list. The documentdigitization engine 120 may take semantic interpolation into account formacroblock identification made from the spacing categories.

Even further, the document digitization engine 120 may also takerelative styling into account for macroblock identification. Thesemantic interpolation and the relative styling generally haverespective weights less than spacing according to absolute and relativemeasurements. The document digitization engine 120 may assign respectiveweights for certain elements based on a class of the document. Forexample, changes in style and fonts between two blocks within a certaindistance range may weigh more for form documents such as transactiondocuments, invoices, and government forms than informal documents suchas presentation slides.

FIG. 5 illustrates a method for macroblock extraction of metadata. Thedocument digitization engine 120 outputs computational data provided bymetadata to one or more process interface e.g. for use in updatingsemantic database 130 so that the taxonomical report improves processingby the document digitization engine 120 a next time the documentdigitization engine processes a document image similar to documentimage, for input into a search engine, application to a form, for use ina voice enabled application.

In block 2110 the document digitization engine 120 identifies amacroblock e.g. macroblock 1604D as shown in FIG. 6 including one ormore microblock such as microblocks 1602A-1602K. The identification of amacroblock 1604D (FIG. 6) as set forth herein includes in one embodimentanalyzing adjustable collinear parameters for each microblock. As notedin reference to block 320 (FIG. 3) adjustable collinear parameters mayinclude font; paragraph alignment; punctuation mark; and ontologicalmatching. The document digitization engine 120 in one embodimentidentifies (in block 220, FIG. 2) macroblock 1604D (FIG. 6) usinganother method e.g. application of a classifier such as a table, textdensity, address, or paragraph classifier. The document digitizationengine 120 may iterate block 2110 until all macroblocks of a documentimage are identified. In the case a specialized macroblock isrecognized, e.g. a table, specialized macroblock processing may proceed.In all cases generical macroblock processing as described in blocks 2110may proceed.

In block 2120 the document digitization engine 120 uses the identifiedmacroblock e.g. macroblock 1604D to find key-value pairs (KVPs). Theidentified KVPs may supplement any previously identified KVPs e.g.identified during a process to identify macroblock 1604D. Using theidentified macroblock 1604D to find KVPs includes in one embodiment thedocument digitization engine 120 iteratively applying differentmicroblock delineation machine logic rules so that different sets ofmicroblocks are identified relative to the same content within amacroblock. With microblocks within a macroblock identified, thedocument digitization engine 120 in one embodiment on finding a “key”within one microblock searches each remaining microblock within themacroblock for a value corresponding to the key.

In block 2130 the document digitization engine 120 evaluates identifiedKVPs which may include associated confidence levels. For performance ofblock 2130 in one embodiment the document digitization engine 120assigns a confidence level to each identified KVP. The documentdigitization engine 120 heuristically determines the confidence level ofa KVP based on various factors such as the level of proximity,ontological matching of respective key names and data types. For keysand values frequently appearing in formal and transactional documents,the confidence levels of KVPs may be higher than custom keys and valuesin informal and personal documents. In one embodiment, the documentdigitization engine 120 applies as a factor for assigning a confidencelevel to a KVP whether the KVP has been previously determined to belongto a common macroblock. Thus, the document digitization engine 120 mayassign a higher confidence level to the same two microblocks beingevaluated as a KVP depending on whether the evaluation is performed(e.g. at block 320 FIG. 3) prior to identification of the key-value pairas belonging to a common macroblock, or (e.g. at block 2130) after amacroblock is identified that commonly encompasses microblocks beingcompared. Processing in blocks 2120 and 2130 in one embodiment isdescribed further in reference to FIGS. 6-8.

Based on assigned confidence levels in block 2130 one or more KVPssubject to evaluation may be discarded or treated as titles (effectivekeys without values). In one embodiment, the document digitizationengine 120 applies low-soft matching that is heuristically set atbetween 0-70% and high precision matches at 100%. The absence orretreatment of delimiters forms a major part of this ranking once thevalues are extracted.

In block 2140 the document digitization engine 120 providescomputational data in the form of metadata for user editing. In block2150 document digitization engine 120 outputs metadata e.g. to a processinterface 149. Aspects of processing at block 2140 and 2150 aredescribed further in reference to FIGS. 6 through 8.

FIG. 6 depicts an illustrative document image 1600 having macroblock1604D identified by the document digitization engine 120. For example,the document digitization engine 120 may initially recognize microblocks1602A-1602K and apply collinearity based block identification processing(FIG. 3 in block 320) to determine that macroblock 1604D is a macroblockencompassing microblocks 1602A. In another embodiment, macroblock 1604Dmay be recognized as a macroblock without prior recognition ofmicroblocks 1602A-1602K e.g. using an applied classifier such as a tableclassifier, a word density classifier (an area where text density isabove a threshold may be identified as a macroblock), an addressclassifier, a paragraph classifier. Embodiments herein recognize thatalignment of objects may indicate “belonging” and therefore macroblocksthat are identified areas useful to search for the presence of key-valuepairs for instance. The document digitization engine 120 may delineateeach identified microblock and macroblock with a rectilinear border.FIG. 7 illustrates the document image 1600 segmented alternativelyaccording to application of a second microblock machine logicdelineation rule, and FIG. 9 illustrates computational data provided bymetadata output by the document digitization engine 120 based onprocessing of document image 1600.

As set forth herein the document digitization engine 120 may for eachmicroblock of a document identify a macroblock by analyzing adjustablecollinear parameters for each microblock. As noted in reference to block320 (FIG. 3) adjustable collinear parameters may include font; paragraphalignment; punctuation mark; and ontological matching. In reference FIG.6 the document digitization engine 120 may identify macroblock 1604A asencompassing microblock 1602B and 1602C based on alignment and onontology in spite of the font size differential. In reference FIG. 6 thedocument digitization engine 120 may identify macroblock 1604B asencompassing microblock 1602D and 1602E based on alignment. In referenceFIG. 6 the document digitization engine 120 may identify macroblock1604C as encompassing microblock 1602F and microblock 1602G based onalignment and on ontology in spite of the font size differential. Thedocument digitization engine 120 may identify macroblock 1604D asencompassing microblocks 1602A, 1602B, 1602D, 1602F, 1602H, and 1602Kbased on left side alignment between microblocks 1602A, 1602B, 1602D,1602F, 1602H, and 1602K and hence establish macroblock 1604Dencompassing microblocks 1602A, 1602B, 1602D, 1602F, 1602H, and 1602K aswell as the remaining microblocks of microblocks 1602A-1602K based onright side border of microblock 1602K and the rectilinear configurationof macroblock 1604D. Thus, on completion of identification of macroblock1604D, macroblock 1604D is determined to include microblocks1602A-1602K. For determining macroblock 1604D from microblocks1602A-1602K a first microblock delineation machine logic rule may beapplied. According to a first microblock machine logic rule for example,double spaces between text segments may be ignored for purposes ofmicroblock delineation. Accordingly, as shown in FIG. 6 microblocks1602H-1602J are identified respectively as single microblocks.

With macroblock 1604D defined as shown in FIG. 6 the documentdigitization engine 120 may identify key-value pairs within macroblock1604D. Identification of key-value pairs with macroblock 1604Didentified may supplement a prior identification of key-value pairsperformed for the identification of macroblock 1604D in the casemacroblock 1604D has been identified by analysis of analyzing adjustablecollinear parameters for each microblock. Identification of key-valuepairs with macroblock 1604D identified in one embodiment is an initialkey-value pair identification.

For identification of key-value pairs with macroblock 1604D defined asshown in FIG. 6 the document digitization engine 120 identifiesmicroblocks within macroblock 1604D. In one embodiment, the documentdigitization engine 120 may use the microblocks 1602A-1602K as shown inFIG. 6 to search for and identify key-value pairs using the firstmicroblock delineation rules (wherein double spaces are ignored and donot result in a delineation between microblocks).

In one embodiment, referring to FIG. 7 the document digitization engine120 may apply various microblock delineation machine logic rules foridentification of microblocks and in one embodiment may iterativelychange microblock machine logic delineation rules for the identificationof microblocks within a macroblock 1604D for purposes of expanding asearch for key-value pairs (KVPs).

For identification of microblocks as shown in FIG. 7 the documentdigitization engine 120 identifies microblocks 1603A-1603N on the basisof a second machine logic rule microblock delineation rule whereindouble spaces between microblocks are observed (rather than ignored) forpurposes of delineation of a microblock; that is a double space betweentwo text segments results in identification of two microblocks ratherthan a single microblock. The second machine logic rule results in theidentification of additional microblocks, and therefore additional basesfor identification of key-value pairs. With macroblock 1604D identifiedas set forth in FIG. 7 the document digitization engine 120 may use thenewly identified microblocks 1603A-1603N to identify key-value pairs.For each key located in a microblock of microblocks 1603A-1603N thedocument digitization engine 120 may search for and identify acorresponding value within another microblock of microblocks1603A-1603N. In the described example, the document digitization engine120 identifies key-value pairs based on the content of microblocks1603A-1603N. With the identification of additional microblocks1603H-1603M (six microblocks identified in text in which threemicroblocks are identified using the first machine logic microblockdelineation rule) the document digitization engine 120 may performadditional searching but the additional searching is economized and oflow latency based on the additional searching being confined to thedocument image area of macroblock 1604D.

In one embodiment, a first microblock delineation machine logic rulethat identifies fewer microblocks 1602A-1602K is applied forestablishment of macroblock 1604D and key-value pairs and a secondmachine logic microblock delineation machine logic rule that identifiesadditional newly defined microblocks 1603H-1603M) (FIG. 7) within themacroblock 1604D (once established) is applied for identification ofkey-value pairs. Thus, in one embodiment ontological relationshipsidentified using relatively coarsely defined microblocks may yieldidentification of a region of interest (a macroblock) which region ofinterest may then be subject to further analysis (which further analysismay include identification of relatively finely defined microblockstherein for extraction of KVPs).

With key-value pairs identified using microblocks 1602A-1602K andmicroblocks 1603A-1603N the document digitization engine 120 in oneembodiment continues to identify key-value pairs using macroblock 1604De.g. by identifying newly defined microblocks within macroblock 1604Dusing further changed microblock delineation machine logic rules andidentifying new key-value pairs within macroblock 1604D based on thenewly defined microblocks. According to one further changed microblockdelineation rule for example the document digitization engine 120 in oneembodiment observes rather than ignores a single space as an elementdelineating between microblocks. According to one further changedmicroblock delineation rule for example the document digitization engine120 in one embodiment observes rather than ignores a hyphen “−” as apunctuation element delineating between microblocks. According to onefurther changed microblock delineation rule for example the documentdigitization engine 120 in one embodiment observes different linepresentment as an element delineating between microblocks.

Application of processes to identify key-value pairs both for or beforethe establishing of a macroblock and after establishing the macroblockprovides advantages. Referring to FIG. 8 document image 1700 may includemicroblock 1702A microblock 1702B and microblock 1702C. During initialprocessing (e.g. according to block 320, FIG. 3) analyzing adjustedcollinear parameters between microblock 1702A and microblock 1702B mayfail trigger output of a key-value pair e.g. based on a confidence levelassociated with an identified key-value pair being below a threshold.During initial processing analyzing adjusted collinear parameters asbetween microblock 1702B and microblock 1702C may fail trigger output ofan identified key-value pair e.g. based on a confidence level associatedwith an identified key-value pair being below a threshold. However,during initial processing analyzing adjusted collinear parameters asbetween microblock 1702A and microblock 1702C may successfully triggeroutput of an identified key-value pair e.g. based on a confidence levelassociated with an identified key-value pair being above a threshold(e.g. based on the key “address” ontologically matching content of theaddress field as determined using key ontology data 137 of semanticdatabase 130).

Based on content of microblock 1702A and microblock 1702C defining akey-value pair, macroblock 1704A (which by applied machine logic may beconstrained to be rectilinear in shape) may be established so thatmicroblock 1702B is encompassed within macroblock 1704A based on theontological relationship between microblock 1702A and microblock 1702C.In the described example the document digitization engine 120 may beconfigured so that content of microblock 1702B is examined with contentof microblock 1702A (or microblock 1702C) for identification of akey-value pair multiple times, for example (a) a first time before theestablishment of macroblock 1704A and (b) a second time after theestablishment of microblock 1704A which establishes microblock 1702B asbeing included within the macroblock 1704A encompassing microblock 1702Amicroblock 1702B and microblock 1702C. In one embodiment, the documentdigitization engine 120 may assign a higher (possibly thresholdexceeding) confidence level to a candidate key-value pair resulting fromthe examining the second time based on the new information (resulting inadditional applied weight) that the corresponding microblocks have beendetermined to be of a common macroblock. Thus, it is seen thatidentification of a KVP between content of first and second microblocks(e.g. microblocks 1702A and 1702C) that are unaligned may assist in theoutput of additional KVPs based on the establishing of a macroblockencompassing the first and second microblocks and potentially additionalmicroblocks.

Exemplary metadata 140 for user editing based on processing of themacroblock 1604D of FIGS. 6 and 7 is shown in FIG. 9. The exemplarymetadata 140 for user editing based on processing of the macroblock1604D as shown in FIG. 9 may be presented in a user interface fordisplay on display of user device 110. The metadata for user editing inFIG. 9 includes text based representations of confidence levels of eachidentified and user controls (Y/N) associated to the confidence levelspermitting an administrator user to accept or reject a key-value pairfor output.

The user using user device 110 may accept or reject each candidate KVPdepicted using controls (Y/N). The document digitization engine 120accordingly provides for self-guiding of an output metadata withoutrequiring multiple training sets even where a received document subjectto processing is a new document with no corresponding document class 131in semantic database 130. Embodiments herein recognize that while theability of the document digitization engine 121 to process a documentimage may be expected to improve with training as set forth hereinuseful metadata should not be predicated on training, but rather shouldprovide useful metadata even where a document is a first document of aclass. As seen by the metadata 140 of FIG. 9 a user may accept or rejectfound KVPs using a user interface using controls (Y/N). The userinterface functionality associated to metadata depicted in FIG. 9 mayinclude functionality whereby if the administrator user finds that thepercentage extracted is low they click on a guide and go to a documentrepresentation and make additional corrections to the KVP determinationswith confidence levels provided by the document digitization engine 120.

In block 2150 based on the provided metadata for user editing and basedon selections of a user the document digitization engine 120 may outputmetadata 140 e.g. is shown in FIG. 9 (all identified KVPs accepted)potentially with some of the metadata presented to the user discardedbased on the user selections. It will be understood that the documentdigitization engine 120 may be configured to proceed directly to outputputting metadata e.g. to a process interface 149 based on all confidencelevels being above a threshold which may be more likely with a reliableand trained document class 131 in semantic database 130.

For providing the metadata 140 shown in FIG. 9 the document digitizationengine 121 reverse engineers a taxonomy based on identified macroblocks(e.g. encompassing two or more microblocks), identified microblocks andidentified KVPs. The KVP organization into the metadata depicted in FIG.9 is a reverse engineering of macro to micro block relationships.Considering that a single page of document image 181 may contain zero toM macroblocks, and each macroblock may contain zero to N microblocks,the candidate KVPs from each macroblock are assembled together in ahierarchy. Thus, in the example described the document digitizationengine 120 may identify zero to M macroblocks for a document page andmay assign a heading such as title for each microblock such as the title“Payment Details:” for the representative metadata 140 as shown in FIG.9.

Referring to the output metadata 140 of FIG. 9, document digitizationengine 120 may output metadata that is organized to specify a taxonomyindicating hierarchical relationships between objects of a documentimage 181. For example, in output metadata as indicated in FIG. 9,output metadata may presented in a form wherein individual KVPs that areextracted are associated to designators for the macroblocks in whichthey were discovered. Under the heading “Payment Details:” the taxonomyillustrated in FIG. 9 may include indicators of various KVPs. As shownin the example of FIG. 9 document digitization engine 120 may presentthe KVPs subheaded under a designator title (the title “PaymentDetails:”) of their associated macroblock 1604D.

As shown in the example 9 the KVPs of metadata 140 may be presented inan order based on content of the document image 1600 (FIGS. 6 and 7).However, according to another embodiment, document digitization engine120 may present KVPs according to an order that is not determined by anorder of objects of a document image 1600. For example documentdigitization engine 120 may present KVPs, e.g. organized under anassociated microblock designator, according to an order based onconfidence level associated to the KVPs. In one embodiment, documentdigitization engine 120 may present KVPs, e.g. organized under anassociated microblock designator, according to an order based on topicclassification of the KVPs, e.g. according to a topic classificationhierarchy. The document digitization engine 120 may employ NaturalLanguage Processing (NLP) topic classification or NLP understandingprocessing (of external tools 170) for determining attributes of ataxonomy specified by output metadata. For example, in some use cases itmay be useful to prioritize KVPs classified according to the topic“demographic” over KVPs that have not returned any classification whensubject to topic based NLP processing, for example. The KVPs mayalternatively be presented in an order that is based on the methodologyfor discovery of the KVP. In one embodiment, KVPs found usingmicroblocks identified using a first microblock delineation machinelogic rule (resulting in less microblocks being identified) may bepresented before KVPs found using microblocks identified using a secondmicroblock delineation machine logic rule (resulting in more microblocksbeing identified). In one embodiment, KVPs found via the processing inblock 320 (FIG. 3) may be presented before KVPs found via the processingin block 2120 (FIG. 5). In one embodiment, KVPs found in a manner so asto infer a key associated to a value may be presented below KVPs where aKVP is expressly defined according to a document class 131 of semanticdatabase 130. Output metadata that is organized to specify a taxonomyindicating hierarchical relationships between objects of a documentimage 181 provides numerous advantages e.g. ease of handling bydownstream processes which become less reliant on rules based machinelogic for processing of the metadata.

The document digitization engine 120 may employ Natural LanguageProcessing (NLP) topic classification or NLP understanding processing(of external tools 170) for determining values of identified microblockscorresponding to identified candidate keys. For example, a key-pairidentification may be provided if subjecting text of a microblock to NLPtopic classification returns a topic or understanding matching the keyor an alias of the key. A key-pair identification may also be providedif a topic returned by subjecting a first microblock to NLP topicclassification matches a topic returned by subjecting a secondmicroblock to NLP topic classification. Where subjecting text of amicroblock to NLP topic classification results in a diversity of topics,the document digitization engine 120 may apply a generic “comment” keyto the microblock.

Referring to the metadata of FIG. 9 output metadata may include metadataof latent KVPs without consistent structure or format. Embodimentsherein provide for extraction of latent KVPs, e.g. KVPs withoutpunctuation delimiters (like a colon “:”), KVPs having values withinferred keys correctly into a formal taxonomy. Embodiment hereinprovide for macroblock and microblock processing in connection ontologydata of semantic database 130 to identify candidate keys and values.

Embodiments herein process documents including unstructured documents topresent computational data to the consumer in a structured format, e.g.JSON or XML. Embodiments herein endeavor to extract text in a consumablefashion and to preserve styling information. Embodiments herein providemetadata that does not merely specify styling information (e.g. fontsize), but provides relative styling information, such as the height(size) of font in an area of a document image relative to a larger shareof a document image. Relative styling information may be provided byrelative styling parameter values as set forth herein. Text may be inbold or may have a variation in font height (size) or style. To a humanreader, when done appropriately, these changes in style may convey aspectrum of emphasis; from a subtle comparison using italics to largerfonts that convey headers or some other form of information that is notcontained in the syntactic or semantic content. Embodiments hereinrecognize that styling is a crucial yet challenging element to preserve.Embodiments herein set forth to provide relative styling information inmetadata so as emulate human cognitive classification of patterns,wherein patterns tend to be classified in relative terms and notabsolutes. With the relative styling information provided as machinereadable computational metadata, the relative styling informationfacilitates a wide range of processes.

Embodiments herein recognize that while newer versions of PDF documentscontain a backing XML structure which may preserve some stylinginformation, styling information that is available is limited. Forexample, according to available technologies for processing a PDFdocument each object may be classified as having has its own font, fontsize, and color space. Embodiments herein recognize that organizationshave vast numbers of PDF documents, many with no backing metadata.

Embodiment herein extract styling information from a document image forproviding “relative styling information” from said document image.

In one embodiment, the document digitization engine 120 is configured toprocess a document image having text so that information in addition tothe font type and size and font color is provided. Thus, for a segmentof text in Helvetica 24 pt. the document digitization engine 120 mayprovide the output: 24 pt. Helvetica. Further, the document digitizationengine 120 may extract and output relative styling information. Relativestyling information may include the data e.g. that the text segment hasa font (character) height (size) 10% higher than its neighbor or 50%higher, or 20% lower. The document digitization engine 120 may provideadditional or alternative characterizing information regarding the font,e.g. may classify fonts into such classification as “business font” or“recreational font”.

Configuring the document digitization engine 120 to output metadata thatincludes relative styling information improves text transformation, e.g.for the case that output metadata is output to a form regenerator oranother process interface. The document digitization engine 120 may beconfigured for use in transforming text from an unstructured documentinto a format for display on an electronic device e.g. PC environment ormobile device. In one embodiment, the document digitization engine 120may output metadata formatted in a stylesheet such as a Cascading StyleSheet (CSS) based on a processed document having relative stylinginformation corresponding to relative styles of the processed document.In addition to or in place of performing a line-by-line conversion ofsource-to-target, where the styling information is specified in anidentical manner, the document digitization engine 120 may output a CSSwith relative styling information.

In one embodiment, for processing a document to output a CSS havingrelative styling information, the document digitization engine 120 mayperform a larger area e.g. whole document analysis. By performing alarger area document analysis, the document digitization engine 120 maydetermine a baseline styling parameter value (or set of baseline stylingparameter values) such as a baseline font height (size) parameter and orbaseline white space size parameter for a document, and based on adetermined one or more baseline styling parameter values the documentdigitization engine 120 may provision a stylesheet to inherit and alterthese styles. If the original content had a section (e.g. word in a lineof text) that was 10% higher than its neighbor, then this relativeheight information providing a relative styling parameter value may berepresented in CSS. For example, the use of “font height: 80%;” in astyling block would create a style that refers to the parent element'sfont height (size), but was 20% lower.

The described processing provides a concept-by-concept conversion.Regardless of whether the intent is to perform a transformation fromsource-to-target, the extraction of relative styling information allowsthe non-semantic and non-syntactic emphasis present in stylinginformation to be preserved for any downstream process.

For providing relative font height data defining a relative stylingparameter value document digitization engine 120 may initially determinea baseline styling parameter value provided by a baseline font heightfor a document in an area of the document that is larger than a word,e.g. a full page of a document. For determining a font height baselinestyling parameter, document digitization engine 120 may construct ahistogram of word font heights throughout a document and a baselinestyling parameter value may be determined based on a central dispersionof the histogram, e.g. a mean or median of font height values. On a textline by text line basis, document digitization engine 120 may assign arelative font height relative styling parameter value for each word e.g.as a percentage of the relevant baseline styling parameter value. Insome embodiments baseline styling parameter values may be determinedbased on macroblock specific data (rather than full page data) or acombination of macroblock and global page data. In some embodimentK-means clustering analysis may be performed for determination of a fontheight baseline styling parameter value.

Relative styling information provided as part of output metadata 140 mayinclude relative styling information on white spaces of a document(areas absent of text or other objects). For providing white spacerelative styling information for objects defining relative stylingparameter values document digitization engine 120 may initiallydetermine a white space baseline styling parameter value for a documentin an area of the document that is larger than segment of line, e.g. afull page of a document. For determining a white space baseline stylingparameter value, document digitization engine 120 may construct ahistogram of white space sizes throughout a document and a baselinevalue for a baseline styling parameter value may be determined based ona central dispersion of the histogram, e.g. a mean or median of whitespace sizes. On a text line by text line basis, document digitizationengine 120 may assign a white space relative styling parameter value foreach white space of the line expressed as a percentage of the whitespace baseline styling parameter value. Thus, a double space white spacemight equate to a value of 101 (101% of baseline) for a normal document,but 150% for a document with highly dense text or 50% for a documentwith highly sparse text. In some embodiments baseline styling parametervalues may be determined based on macroblock specific data or acombination of macroblock and global page data. In some embodimentsK-means clustering analysis may be performed for determination of awhite space baseline styling parameter value.

For providing the classifications of “business font” or “recreationalfont” the document digitization engine 120 may examine a lookup tablethat cross references fonts with respective “business font” or“recreational font” classifications. Fonts such as Baskerville or TimesNew Roman might be classified as “business fonts” whereas fonts such asArial may be classified as recreational fonts.

Providing relative styling information may enhance the functioning ofdownstream processes having functions based on received metadata outputby document digitization engine 120. For example, development of formregenerators may be automated or simplified based on output metadatahaving relative font height (size), white space or font typeclassifications to define relative styling parameter values. Forexample, in form regenerator machine logic, relative font height dataindicating a sudden change to large font height may be examined anddetermined to represent a generic highlight rather than a specifichighlight requiring reproduction of font height. For example, in theform regenerator output the sudden increase in font height may beexpressed instead or also with a change in color e.g. from black to redindicative of a highlight. Where a form regenerator moves content toaccommodate display on a specifically sized display, white spacerelative styling information (e.g. white space relative stylingparameter values) in the context of white space baseline stylingparameter values may be examined to verify that an adjustment will notyield an unacceptable change in the overall impact of provided by achange. The providing of font type classification (“business” and“recreational”) avoids a need for example to access missing fonts fromexternal resources. Relative styling information reduces complexity ofmachine logic for processing of output metadata.

FIG. 10 depicts an exemplary document metadata 140 corresponding to thedocument image 181, in accordance with one or more embodiments set forthherein.

The document digitization engine 120 processes the document image 181and generates the document metadata 140. In certain embodiments of thepresent invention, the document digitization engine 120 generates thedocument metadata 140 in JavaScript Object Notation (JSON) format, asshown in the exemplary document metadata 140 of FIG. 10. The documentimage 181 is hierarchically organized as one or more block, whichincludes one or more line. Each line has one or more word. Each block,line, and word may be deemed as respective object within the documentimage 181, of which properties are respectively described in thedocument metadata 140.

Lines L401 indicates that the list describes a block represented by“BlockList”. Lines L402 and L403 represent (x,y) coordinates of astarting point of the block. Line L403 indicates no remark is attachedto the block. Line L403 indicates that the block is of a certain width.Line L406 indicates that the block has a line represented by “LineList”.

Line L407 indicates that the line “LineList” has a word represented by“WordList”. Line L408 indicates that the word has a value “XYZ Inc.”,lines L409 and L410 respectively indicate height and density of theword. The height is specified to have a value of 204 to indicate thatthe height of the word is 204% of a baseline styling parameter value.Additional words of a line may be expressed with additional percentagevalues to the extent that have different heights. The value 204 or 204%may be given in the illustrative example of FIGS. 6 and 7 for the word“ANZ” “BANK” and “Winnellie” and the value 99 (99 percent) for the word“bank”. Lines L411 and L412 represent (x,y) coordinates of a startingpoint of the word. Line L413 indicates a font height (size) of the word,as in a certain custom font size group, for further characterization ofthe font height (size) data. Line L414 indicates that the word would beidentified by a “word_0” name. Line L415 indicates that the word haseight (8) characters, and line L426 indicates that the word is of acertain width. Measurement may be in pixel units, or according to anyother custom units.

Lines L417 through 421 concludes the line “LineList” introduced in L406.A width of the line in L417, (x,y) coordinates of a starting point ofthe line in lines L418 and L419, a height of the line in Line L420, anda name “line_0” to identify of the line in line L421.

The context of an object is represented by how each object appears in acertain list together. Relative positioning and sizes of the objects maybe determined based on various coordinates and dimensional elements suchas height and width. The document metadata 140 is used as an input tothe semantic normalization engine 160, particularly in order to assess aconfidence score on a likelihood of a candidate key being an alias to aknown key.

Lines L511 through L521 depict illustrative KVP metadata. Line L512indicates that the candidate key is a member of a block identified by“block_16” name. “Block_16” may be specified in the document metadatafor a context, position, and style. Line L513 indicates that a value ofthe candidate key is “573093486”. Lines L514 and L515 indicate (x,y)coordinates of a starting point of the value of L513. Lines L516 andL517 indicate (x,y) coordinates of a starting point of the candidatekey. Line L518 indicates that the candidate key has a text “Accnt No”.Line L519 indicates that document digitization engine 120 determinesthat the key class “customerAccountNumber” is 82.35% likely to be a keyclass corresponding to the candidate key “Accnt No”, based on thecontext, relative positioning, and styles represented in the documentmetadata, text sequencing, semantic matching, and vector space modelingand text classification. Output metadata 140 may specify a taxonomyindicating an organization and hierarchy among objects as set forth inconnection with FIGS. 9 and 10.

The document digitization engine 120 may output metadata to a pluralityof process interfaces. For example, output metadata may be used to (a)automatically adapt processes of document digitization engine 120, (b)accelerate information management, (c) accelerate a chat box, and/or (d)augment form generation.

Regarding (a) the document digitization engine 120 may adapt one or moreprocess run by document digitization engine 120 based on outputmetadata, e.g. using relative styling information of output metadata asset forth herein. In one embodiment, document digitization engine 120may automatically adjust a microblock delineation machine logic rulebased on a white space baseline styling parameter value and/or a whitespace relative styling parameter value (e.g. as may be determined on atext line by text line basis according to one embodiment). For example,in the case of a relatively sparse page with large white spacesmicroblock delineation rules may be selectively enabled and activatedthat are less inclusive and identify fewer microblocks over a certainarea (e.g. delineation triggered with a 5 space white space). In thecase of a dense page with smaller white spaces microblock delineationrules may be selectively enabled and activated that are more inclusiveand identify more microblocks over the certain area, e.g. whereinmicroblock delineation is triggered with a 2 space (double space) whitespace.

Further regarding (a) the document digitization engine 120 may updatesemantic database 130 using output metadata e.g. as shown in FIGS. 9 and10. For example, in reference to the metadata of FIGS. 9 and 10 documentdigitization engine 120 may recognize e.g. via NLP processing that“Account Name” of document image 1600 is a prospective alias for the key“account number”. By the output of metadata for updating semanticdatabase 130, key ontology data 137 may be updated to include “accountname” as a formal alias for “account number”.

Regarding (b) the document digitization engine 120 may output metadata140 to accelerate an information management service. Inputting metadata140 as shown in FIGS. 9 and 10 into a search engine means that indexfields will be identified with high precision. Rather than treating “BSB015896 Account 2856-98739 Swift Code ANZBAU3M” as a single value(associated with some other index), the search engine may treat this asindex=BSB, value=015896, datatype=Integer index=Account Number,value=285698739, datatype=Integer etc. In one embodiment, documentdigitization engine 120 may be provided as search engine interface forperformance of search engine searched. Document digitization engine 120configured as a search engine interface may receive search enginerequests provided by unstructured document such as may be provided byPDF documents. Document digitization engine 120 may output metadataresulting from processing of such documents to a search engine forreturn of useful search results.

Regarding (c) the document digitization engine 120 may be provided as achat interface and may be configured to access an unstructured documentsuch as the document corresponding to document image 1600 for purposesof responding to questions presented in a chat environment. Forresponding to the question “What is the BSB for ANZ Bank Winnellie?”document digitization engine 120 may access and process the documentcorresponding to document image 1600, recognize fully-spanned semanticentities using high precision without noise. Based on processing bydocument digitization engine 120 the question becomes one of: “What isthe <key> for <value>? Or What is the <value> for <key>? and by basicquery algebra: What is the <key:BSB> for <value:ANZ Bank Winnellie> theanswer is <015896>.

Regarding (d) the document digitization engine 120 may be used as a formregeneration tool. The document digitization engine 120 may outputmetadata to a form regenerator which regenerates the information of thedocument corresponding to the document image 181. The form regeneratorreceiving metadata 140 may regenerate this data into a form suitable formobile or web or some other usability paradigm. For example, developmentof form regenerators may be automated or simplified based on outputmetadata having relative styling parameters such as relative stylingparameters specifying font height (size), white space or font typeclassifications. For example, a configured form regenerator applyingmachine logic may perform examining relative font height relativestyling information and based on the examining may determine that asudden change from small height font to large height font represents ageneric highlight rather than a specific highlight requiringreproduction of font height. For example, in an output provided by theform regenerator the sudden increase in font height may be expressedinstead or also with a change in color e.g. from black to red indicativeof a highlight. Where a form regenerator moves content to accommodatedisplay on a specifically sized display, white space relative stylinginformation in the context of white space baseline styling parametervalues may be examined to verify that an adjustment will not yield anunacceptable change in the overall graphical impact of provided by achange. The providing of font type classification (“business” and“recreational”) avoids a need for example to access missing fonts fromexternal resources. Relative styling information reduces complexity ofmachine logic for processing of output metadata.

Certain embodiments herein may offer various technical computingadvantages involving computing advantages to address problems arising inthe realm of computer networks. Digital documents are often preferredfor the convenience in computationally using data represented in thedocuments. When pen-on-paper documents are scanned in, the documents area series of visual image of pages, but not computationally ready forusage as digital data. Accordingly, many document digitizationapplications have been developed in order to accurately extractcomputational data from document images. In existing document processingapplications, numerous custom formats and organizations of documentspresent challenges in processing visual images of a document andextracting computational data out of the document. Embodiments hereinimplement a cognitive digitization process of document images as humanreaders understand meanings conveyed by visual marks in documents, andimproves efficiency and accuracy of data extraction from documentimages. Embodiments herein provide for control of processes usingmetadata derived by processing of documents which may be provided byunstructured documents. Embodiments herein extract metadata fromdocuments by methods that are not reliant solely on alignment of objectsor on semantical relationships between objects but rather which employ acombination of alignment based processing and semantics basedprocessing.

FIGS. 11-13 depict various aspects of computing, including a computersystem and cloud computing, in accordance with one or more aspects setforth herein.

It is understood in advance that although this disclosure includes adetailed description on cloud computing, implementation of the teachingsrecited herein are not limited to a cloud computing environment. Rather,embodiments herein are capable of being implemented in conjunction withany other type of computing environment now known or later developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g. networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that maybe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities may be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and may bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage may bemonitored, controlled, and reported providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based e-mail).The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, storage,or even individual application capabilities, with the possible exceptionof limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure comprising anetwork of interconnected nodes.

Referring now to FIG. 11, a schematic of an example of a computing nodeis shown. Computing node 10 is only one example of a computing nodesuitable for use as a cloud computing node and is not intended tosuggest any limitation as to the scope of use or functionality ofembodiments of the invention described herein. Regardless, computingnode 10 is capable of being implemented and/or performing any of thefunctionality set forth hereinabove. Computing node 10 may beimplemented as a cloud computing node in a cloud computing environment,or may be implemented as a computing node in a computing environmentother than a cloud computing environment.

In computing node 10 there is a computer system 12, which is operationalwith numerous other general purpose or special purpose computing systemenvironments or configurations. Examples of well-known computingsystems, environments, and/or configurations that may be suitable foruse with computer system 12 include, but are not limited to, personalcomputer systems, server computer systems, thin clients, thick clients,hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputer systems, mainframe computersystems, and distributed cloud computing environments that include anyof the above systems or devices, and the like.

Computer system 12 may be described in the general context of computersystem-executable instructions, such as program processes, beingexecuted by a computer system. Generally, program processes may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system 12 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program processes may belocated in both local and remote computer system storage media includingmemory storage devices.

As shown in FIG. 11, computer system 12 in computing node 10 is shown inthe form of a general-purpose computing device. The components ofcomputer system 12 may include, but are not limited to, one or moreprocessor 16, a system memory 28, and a bus 18 that couples varioussystem components including system memory 28 to processor 16. In oneembodiment, computing node 10 is a computing node of a non-cloudcomputing environment. In one embodiment, computing node 10 is acomputing node of a cloud computing environment as set forth herein inconnection with FIGS. 12-13.

Bus 18 represents one or more of any of several types of bus structures,including a memory bus or memory controller, a peripheral bus, anaccelerated graphics port, and a processor or local bus using any of avariety of bus architectures. By way of example, and not limitation,such architectures include Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnects (PCI) bus.

Computer system 12 typically includes a variety of computer systemreadable media. Such media may be any available media that is accessibleby computer system 12, and it includes both volatile and non-volatilemedia, removable and non-removable media.

System memory 28 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 30 and/or cachememory 32. Computer system 12 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 34 may be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media may be provided.In such instances, each may be connected to bus 18 by one or more datamedia interfaces. As will be further depicted and described below,memory 28 may include at least one program product having a set (e.g.,at least one) of program processes that are configured to carry out thefunctions of embodiments of the invention.

One or more program 40, having a set (at least one) of program processes42, may be stored in memory 28 by way of example, and not limitation, aswell as an operating system, one or more application programs, otherprogram processes, and program data. One or more program 40 includingprogram processes 42 can generally carry out the functions set forthherein. In one embodiment, the document digitization engine 120 caninclude one or more computing node 10 and can include one or moreprogram 40 for performing functions described with reference to variousmethods as are set forth herein such as the methods described inconnection with the flowcharts of FIGS. 2, 3, and 5. In one embodiment,the respective components of FIG. 1 that are referenced withdifferentiated reference numerals may each be computing node baseddevices and each may include one or more computing node 10 and mayinclude one or more program 40 for performing functions described hereinwith reference to the respective components.

Computer system 12 may also communicate with one or more externaldevices 14 such as a keyboard, a pointing device, a display 24, etc.;one or more devices that enable a user to interact with computer system12; and/or any devices (e.g., network card, modem, etc.) that enablecomputer system 12 to communicate with one or more other computingdevices. Such communication can occur via Input/Output (I/O) interfaces22. Still yet, computer system 12 can communicate with one or morenetworks such as a local area network (LAN), a general wide area network(WAN), and/or a public network (e.g., the Internet) via network adapter20. As depicted, network adapter 20 communicates with the othercomponents of computer system 12 via bus 18. It should be understoodthat although not shown, other hardware and/or software components couldbe used in conjunction with computer system 12. Examples, include, butare not limited to: microcode, device drivers, redundant processingunits, external disk drive arrays, RAID systems, tape drives, and dataarchival storage systems, etc. In addition to or in place of havingexternal devices 14 and display 24, which may be configured to provideuser interface functionality, computing node 10 in one embodiment caninclude display 25 connected to bus 18. In one embodiment, display 25may be configured as a touch screen display and may be configured toprovide user interface functionality, e.g. can facilitate virtualkeyboard functionality and input of total data. Computer system 12 inone embodiment can also include one or more sensor device 27 connectedto bus 18. One or more sensor device 27 can alternatively be connectedthrough I/O interface(s) 22. One or more sensor device 27 can include aGlobal Positioning Sensor (GPS) device in one embodiment and may beconfigured to provide a location of computing node 10. In oneembodiment, one or more sensor device 27 can alternatively or inaddition include, e.g., one or more of a camera, a gyroscope, atemperature sensor, a humidity sensor, a pulse sensor, a blood pressure(bp) sensor or an audio input device. Computer system 12 can include oneor more network adapter 20. In FIG. 12 computing node 10 is described asbeing implemented in a cloud computing environment and accordingly isreferred to as a cloud computing node in the context of FIG. 12.

Referring now to FIG. 12, illustrative cloud computing environment 50 isdepicted. As shown, cloud computing environment 50 comprises one or morecloud computing nodes 10 with which local computing devices used bycloud consumers, such as, for example, personal digital assistant (PDA)or cellular telephone 54A, desktop computer 54B, laptop computer 54C,and/or automobile computer system 54N may communicate. Nodes 10 maycommunicate with one another. They may be grouped (not shown) physicallyor virtually, in one or more networks, such as Private, Community,Public, or Hybrid clouds as described hereinabove, or a combinationthereof. This allows cloud computing environment 50 to offerinfrastructure, platforms and/or software as services for which a cloudconsumer does not need to maintain resources on a local computingdevice. It is understood that the types of computing devices 54A-N shownin FIG. 11 are intended to be illustrative only and that computing nodes10 and cloud computing environment 50 can communicate with any type ofcomputerized device over any type of network and/or network addressableconnection (e.g., using a web browser).

Referring now to FIG. 13, a set of functional abstraction layersprovided by cloud computing environment 50 (FIG. 12) is shown. It shouldbe understood in advance that the components, layers, and functionsshown in FIG. 13 are intended to be illustrative only and embodiments ofthe invention are not limited thereto. As depicted, the following layersand corresponding functions are provided:

Hardware and software layer 60 includes hardware and softwarecomponents. Examples of hardware components include: mainframes 61; RISC(Reduced Instruction Set Computer) architecture based servers 62;servers 63; blade servers 64; storage devices 65; and networks andnetworking components 66. In some embodiments, software componentsinclude network application server software 67 and database software 68.

Virtualization layer 70 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers71; virtual storage 72; virtual networks 73, including virtual privatenetworks; virtual applications and operating systems 74; and virtualclients 75.

In one example, management layer 80 may provide the functions describedbelow. Resource provisioning 81 provides dynamic procurement ofcomputing resources and other resources that are utilized to performtasks within the cloud computing environment. Metering and Pricing 82provide cost tracking as resources are utilized within the cloudcomputing environment, and billing or invoicing for consumption of theseresources. In one example, these resources may comprise applicationsoftware licenses. Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal 83 provides access to the cloud computing environment forconsumers and system administrators. Service level management 84provides cloud computing resource allocation and management such thatrequired service levels are met. Service Level Agreement (SLA) planningand fulfillment 85 provide pre-arrangement for, and procurement of,cloud computing resources for which a future requirement is anticipatedin accordance with an SLA.

Workloads layer 90 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: mapping andnavigation 91; software development and lifecycle management 92; virtualclassroom education delivery 93; data analytics processing 94;transaction processing 95; and processing components 96 for processingdocument images as set forth herein. The processing components 96 may beimplemented with use of one or more program 40 described in FIG. 11.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium may be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein may bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, may be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general-purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowcharts and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, may be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting. As used herein, thesingular forms “a,” “an,” and “the” are intended to include the pluralforms as well, unless the context clearly indicates otherwise. It willbe further understood that the terms “comprise” (and any form ofcomprise, such as “comprises” and “comprising”), “have” (and any form ofhave, such as “has” and “having”), “include” (and any form of include,such as “includes” and “including”), and “contain” (and any form ofcontain, such as “contains” and “containing”) are open-ended linkingverbs. As a result, a method or device that “comprises,” “has,”“includes,” or “contains” one or more steps or elements possesses thoseone or more steps or elements, but is not limited to possessing onlythose one or more steps or elements. Likewise, a step of a method or anelement of a device that “comprises,” “has,” “includes,” or “contains”one or more features possesses those one or more features, but is notlimited to possessing only those one or more features. Forms of the term“based on” herein encompass relationships where an element is partiallybased on as well as relationships where an element is entirely based on.Methods, products and systems described as having a certain number ofelements may be practiced with less than or greater than the certainnumber of elements. Furthermore, a device or structure that isconfigured in a certain way is configured in at least that way, but mayalso be configured in ways that are not listed.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below, if any, areintended to include any structure, material, or act for performing thefunction in combination with other claimed elements as specificallyclaimed. The description set forth herein has been presented forpurposes of illustration and description, but is not intended to beexhaustive or limited to the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the disclosure. Theembodiment was chosen and described in order to best explain theprinciples of one or more aspects set forth herein and the practicalapplication, and to enable others of ordinary skill in the art tounderstand one or more aspects as described herein for variousembodiments with various modifications as are suited to the particularuse contemplated.

What is claimed is:
 1. A method comprising: obtaining a document image,wherein the document image includes a plurality of objects; identifyinga macroblock within the document image, wherein the macroblock includesobjects of the plurality of objects; examining content of microblockswithin an area of the macroblock of the document image for extraction ofone or more key-value pair, wherein the examining includes examiningcontent of unaligned microblocks within the area of the microblock, andwherein the examining content of unaligned microblocks within the areaof the microblock includes applying an ontological analysis; andoutputting the one or more key-value pair.
 2. The method of claim 1,wherein the examining content of unaligned microblocks within an area ofa the macroblock includes iteratively performing the examining usingdifferent machine logic microblock delineation rules so that for a firstiteration a first set of microblocks within the area of the macroblockis identified and for a second iteration a second set of microblockswithin the area of the macroblock is identified, wherein a count ofmicroblocks of the second set of microblocks is different from the countof microblocks of the second set of microblocks.
 3. The method of claim1, wherein the method includes processing the document image to identifya baseline styling parameter value, the baseline styling parameter valuespecifying a baseline font height, identifying for each word of a lineof text of the document image a relative styling parameter, the relativestyling parameter being defined in reference to the baseline stylingparameter value, wherein the relative styling parameter specifies a fontheight of a word of text of the text line as a percentage of thebaseline styling parameter value, and wherein the method includesproviding the relative styling parameter as output metadata for output.4. The method of claim 1, wherein the examining includes analyzingrespective semantic content of both a first microblock and a secondmicroblock within the area of the macroblock, ascertaining that firstsemantic content of the first microblock is associated with a key name,discovering, from key ontology data corresponding to the key name, thata second semantic content of the second microblock is of a data typecorresponding to the key name.
 5. The method of claim 1, wherein theexamining content of unaligned microblocks is commenced prior to theidentifying a macroblock, and wherein the identifying a macroblockwithin the document image is performed based on the examining content ofunaligned microblocks.
 6. The method of claim 1, wherein the examiningcontent of unaligned microblocks includes performing the examining in afirst iteration and in a second iteration, wherein the first iterationresults in the identifying the macroblock, and wherein the seconditeration is performed subsequent to the identifying the macroblock. 7.The method of claim 1, wherein the examining content of unalignedmicroblocks includes performing the examining in a first iteration andin a second iteration, wherein the first iteration results in theidentifying the macroblock, and wherein the second iteration isperformed subsequent to the identifying the macroblock, wherein theperforming the examining in in a first iteration includes applying afirst machine logic microblock delineation rule to identify relativelyfewer microblocks within the area of the macroblock, wherein performingthe examining in a second iteration rule includes applying a secondmachine logic microblock delineation rule to identify relatively moremicroblocks within the area of the macroblock, wherein the outputtingincludes outputting the one or more key-value pair as metadata to aprocess interface selected from the group consisting of a processinterface for document processing, a process interface for search enginesearching, and a process interface for form regeneration.
 8. A methodcomprising: obtaining a document image, wherein the document imageincludes a plurality of objects; processing the document image toidentify a baseline styling parameter value, the baseline stylingparameter value specifying a baseline font height; identifying for aplurality of words of a line of text of the document image a relativestyling parameter, the relative styling parameter being defined inreference to the baseline styling parameter value, wherein the relativestyling parameter specifies a font height as a percentage of thebaseline styling parameter value; and providing the relative stylingparameter as output metadata for output.
 9. The method of claim 8,wherein the method includes determining the baseline styling parametervalue by providing a histogram of font height values in an area of thedocument that is larger than the line of text, and selecting thebaseline styling parameter value based on a central dispersion of thehistogram.
 10. The method of claim 8, wherein the method includesoutputting the output metadata to a process interface.
 11. The method ofclaim 8, wherein the method includes outputting the output metadata to aprocess interface, wherein the process interface is a form regeneratorthat is configured to examine the relative styling parameter and basedon the relative styling parameter indicating a change in height,changing an attribute of the word other than font height in an outputdocument output by the form regenerator.
 12. A method comprising:obtaining a document image, wherein the document image includes aplurality of objects; identifying a plurality of macroblocks within thedocument image; performing microblock processing within macroblocks ofthe plurality of macroblocks, wherein the microblock processing includesexamining content of microblocks within a macroblock for extraction ofkey-value pairs, the examining content including performing anontological analysis of microblocks; and outputting metadata based onthe performing microblock processing within macroblocks of the pluralityof macroblocks.
 13. The method of claim 12, wherein the outputtingmetadata includes outputting metadata to a process interface.
 14. Themethod of claim 12, wherein the examining content of microblocks withinan area of a the macroblock includes iteratively performing theexamining using different machine logic microblock delineation rules sothat for a first iteration a first set of microblocks within the area ofthe macroblock is identified and for a second iteration a second set ofmicroblocks within the area of the macroblock is identified, wherein acount of microblocks of the second set of microblocks is different fromthe count of microblocks of the second set of microblocks.
 15. Themethod of claim 12, wherein the outputting includes discarding key-valuepairs so that key-value pairs having confidence levels below a thresholdare not subject to outputting.
 16. The method of claim 12, wherein theexamining content includes performing an ontological analysis ofunaligned microblocks, and determining that unaligned microblocks arecollinear based on the ontological analysis.
 17. The method of claim 12,wherein the method includes determining a white space styling parametervalue for an area of the document image larger than a microblock andapplying a machine logic microblock delineation rule based on the whitespace styling parameter value.
 18. The method of claim 12, wherein themethod includes processing the document image to identify a baselinestyling parameter value, the baseline styling parameter value specifyinga baseline font height, identifying for each word of a line of text ofthe document image a relative styling parameter, the relative stylingparameter being defined in reference to the baseline styling parametervalue, wherein the relative styling parameter specifies a font height ofa word of text of the text line as a percentage of the baseline stylingparameter values and wherein the outputting metadata includes providingthe relative styling parameter as output metadata for output.
 19. Themethod of claim 12, wherein the metadata presents a hierarchy includingindications of macroblocks, and identified key-value pairs identifiedand subheaded within designators for each macroblock.
 20. A computerprogram product comprising: a computer readable storage medium readableby one or more processing circuit and storing instructions for executionby one or more processor for performing a method comprising: obtaining adocument image, wherein the document image includes a plurality ofobjects; identifying a plurality of macroblocks within the documentimage; performing microblock processing within macroblocks of theplurality of macroblocks, wherein the microblock processing includesexamining content of microblocks within a macroblock for extraction ofkey-value pairs, the examining content including performing anontological analysis of microblocks; and outputting metadata based onthe performing microblock processing within macroblocks of the pluralityof macroblocks.
 21. The computer program product of claim 20, whereinthe method includes determining a white space baseline styling parametervalue for an area of the document image larger than a microblock andapplying a machine logic microblock delineation rule based on the whitespace baseline styling parameter value.
 22. The computer program productof claim 20, wherein the examining content of microblocks within an areaof a the macroblock includes iteratively performing the examining usingdifferent machine logic microblock delineation rules so that for a firstiteration a first set of microblocks within the area of the macroblockis identified and for a second iteration a second set of microblockswithin the area of the macroblock is identified, wherein a count ofmicroblocks of the second set of microblocks is different from the countof microblocks of the second set of microblocks.
 23. The computerprogram product of claim 20, wherein the outputting includes discardingkey-value pairs so that key-value pairs having confidence levels below athreshold are not subject to outputting.
 24. The computer programproduct of claim 20, wherein the examining content includes performingan ontological analysis of unaligned microblocks, and determining thatunaligned microblocks are collinear based on the ontological analysis.25. A system comprising: a memory; at least one processor incommunication with the memory; and program instructions executable byone or more processor via the memory to perform a method comprising:obtaining a document image, wherein the document image includes aplurality of objects; identifying a plurality of macroblocks within thedocument image; performing microblock processing within macroblocks ofthe plurality of macroblocks, wherein the microblock processing includesexamining content of microblocks within a macroblock for extraction ofkey-value pairs, the examining content including performing anontological analysis of microblocks, wherein the microblock; andoutputting metadata based on the performing microblock processing withinmacroblocks of the plurality of macroblocks.